home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / cbm / 249 < prev    next >
Encoding:
Text File  |  1996-08-05  |  3.0 KB  |  55 lines
  1. Newsgroups: comp.sys.cbm
  2. Path: novice.uwaterloo.ca!dfevans
  3. From: dfevans@bbcr.uwaterloo.ca (David Evans)
  4. Subject: Re: Various Commodore Computers (please read)
  5. Sender: news@novice.uwaterloo.ca (Mr. News)
  6. Message-ID: <DKpv30.HHJ@novice.uwaterloo.ca>
  7. Date: Fri, 5 Jan 1996 16:28:12 GMT
  8. References: <4cbf66$hem@wn1.sci.kun.nl> <30e9b7a3.185sn@fch.wimsey.bc.ca>
  9. Nntp-Posting-Host: bcr.uwaterloo.ca
  10. Organization: University of Waterloo
  11.  
  12. In article <30e9b7a3.185sn@fch.wimsey.bc.ca>,
  13. Dan Fandrich <dan@fch.wimsey.bc.ca> wrote:
  14. >In article <4cbf66$hem@wn1.sci.kun.nl> rhialto@mbfys.kun.nl writes:
  15. >>There was apparently a program published that reliably demonstrated the
  16. >>bug (even though it took a while). I'd like to see that program and
  17. >>the related article (Transactor?).
  18. >
  19. >The October 1985 Compute! (Vol.7,No.10) contains a program which
  20. >demonstrates the bug, and the September 1986 Transactor (Vol.7,Iss.2)
  21. >discusses the causes (at the assembly language level) and provides code to
  22. >fix that bug and several others in the ROM.
  23. >
  24.  
  25.   That's it.  The bug basically went like this, although I'm sure I've left
  26. some things out:
  27.   Buffers are reserved for the BAM from drives 0 and 1 and the BAMs are read
  28. in.  Obviously the one for drive 1 gets an error (drive not ready, likely.)  As
  29. things go along, buffers are moved about; SWAPBUF is called to swap the
  30. contents of two buffers if required and STLBUF is called to "steal" a buffer
  31. that is marked used but is no longer needed.  Two tracks-worth of the BAM is
  32. copied from its buffer to somehwere in zero page (as I recall) in order to ease
  33. work with it.  If buffer space becomes tight, STLBUF will be called.  However,
  34. STLBUF will never steal a buffer which incurred an error.  Thus, the buffer
  35. holding the phantom drive 1 BAM will never be stolen.
  36.   Under certain circumstances, the buffer holding the drive 0 BAM will be
  37. stolen by STLBUF.  Once the drive has finished with its "image" of the BAM in
  38. zero page, it realises it doesn't have the BAM elsewhere and reads it back in
  39. from track 18 sector 0.  This BAM is then updated with the BAM images, another
  40. two tracks of BAM is transferred to the image locations, and things continue.
  41.   The bug strikes if the BAM in the stolen buffer was dirty when it was stolen;
  42. blocks allocated for the newely-save@'d file will no longer be allocated, and
  43. may be clobbered at any time.
  44.   Phillip A. Slaymaker was the guy who wrote the articles in The T. and 
  45. Compute!  He suggested several modifications, including modifying STLBUF to
  46. never steal the drive 0 BAM, modifying STLBUF to be able to steal a buffer with
  47. a "drive not ready" error, and adding aditional buffer space to the drive.
  48.   I know there's more, but I can't remember it all.  :-)
  49.  
  50. -- 
  51. David Evans              (NeXTMail OK)              dfevans@bbcr.uwaterloo.ca
  52. Computer/Synth Junkie                      http://bbcr.uwaterloo.ca/~dfevans/
  53. University of Waterloo         "Default is the value selected by the composer
  54. Ontario, Canada           overridden by your command." - Roland TR-707 Manual
  55.